Cream of the Crop 25/Cream of the Crop 25.iso/os2/srefv12i.zip/srefquik.doc

Text File | 1997-03-04 | 8KB | 184 lines

23 Feb 1997.    The SREFQUIK variant of SRE-Filter.

1) Introduction

SRE-Filter is a full-featured web server. That's nice, but what if
you don't need always need all these features?  Is there some
way to trade-off some of the feature richness in exchange for
increased performance?

The answer is a qualified yes:
  in many cases, if you are willing to do a little bit of extra work,
  you can use the SREFQUIK variant of SRE-Filter.

The main advantage of SREFQUIK is that it is small.
  "Small" is especially advantageous under moderate to heavy load --
  many threads running a "small"  filter will place less strain
  on system resources then the same number of threads running
  the larger "standard" filter.  And since moderate load (say,
  greater then 10 requests simultaneously) is pretty easy
  to achieve (just by serving an inline-image rich document
  to one client), the actual performance impacts can be significant
  even on less-than-busy sites.

So why isn't SRE-Filter running SREFQUIK by default? As they say,
the devil is in the details.


2) Is SREFQUIK right for me?

If ...
  you are serving only 1 host, and
  you have many selectors that you can specify with "literal" PUBLIC_URLS
  or GoServe is caching many requests

then ...

   you can greatly improve throughput by using
   the SREFQUIK.80 filter instead of  SREFILTR.80.

SREFQUIK specializes in processing "literal PUBLIC_URLS" on a single
host server.  Let's review "literal PUBLIC_URLS":

  A "literal PUBLIC_URLS" is a PUBLIC_URL defined with the
  LITERAL or LITERAL_NORECORD option.

  For these PUBLIC_URLS, SRE-Filter will not attempt aliasing,
  virtual directory lookup, access control,or auto_header creation.
  Furthermore, server side includes will NOT be attempted.

  In other words, SRE-Filter will just find the file that the request
  selector maps to, and transfer it (see INITFILT.DOC for the details).

Since "literal" PUBLIC_URLS (actually, selectors that match a PUBLIC_URL
with a LITERAL or LITERAL_NORECORD option) are subject to very little
processing, it makes sense to use a "small" filter that doesn't
bother to try.

That's a good idea, but it's not likely that all you want to do
is serve literal PUBLIC_URLS (if that were the case, you'ld probably
be better off with the generic GoServe filter). Recognizing this
possibility ....
     if the selector does not match a "literal public_url",
     the standard filter is called, with no loss of capability.

Sounds good so far -- but there's more. In addition to "literal
public_urls" (for which little work needs to be done), SREFQUIK will
also handle "cached" responses). "Cached" responses occur when
GoServe was able to resolve the request with a file in it's cache.
   (assuming that GoServe's cache has been enabled -- and if you haven't
   enabled GoServe's cache, then you are missing out on the best
   performance modification you can make).
In such cases, SRE-Filter has almost nothing to do, except record the request:
a chore well suited to a small filter (especially since "recording" is
accomplished simply by transfering information to the "post-filter thread").

:<   Alas, there are drawbacks  :<

 * Since SREFQUIK adds overhead to requests that are NOT to
   "literal public_urls", if you specify few "literal public_urls" the
   net effect may be detrimental. Thus:
       When using SREFQUIK, it is advantageous to specify as many
       "literal public_urls" as possible.

 * If you have specified multiple hosts, SREFQUIK should NOT be used.

 * If you use SREFQUIK, "cached" responses will not be checked for
   the NO_POSTFILTER access permission. That is, SREFQUIK will
   "post-filter" all cached response (that don't match a PUBLIC_URL)

   Although we could directly resolve this problem (by looking up
   the access permissions), for performance reasons we don't want to
   try.  However, SREFQUIK does offer a work around to this problem
   (described in the next section).

What are we to conclude?  If you are willing to specify "literal"
PUBLIC_URLS,  or if you have a lot of files that will be cached,
then it's a good idea to use SREFQUIK.

    In particular, if your documents contain many in-line
    images, most of which you really don't need to keep track of,
    then the use of SREFQUIK can yield significant advantages.

And if you are willing to do a little bit of extra work, you can deal
with the third drawback (as well as further improve performance).

On that note, let's consider the SREFQUIK parameters.



3) SREFQUIK parameters.

SREFQUIK.80 contains a few user-configurable parameters.  These parameters
effect how SREFQUIK.80 deals with "post-filter" activities, including
writing to the common-log audit file and augmenting the RECORD_ALL_FILE.
If you aren't using either mechanism (and if you don't have a custom
post-filter enabled), then you can ignore this section.  Actually, if you
are running such a site (if you are not doing ANY post-filter actions),
you might as well disable the "call filter anyway" GoServe caching option.

There are two (sets) of parameters: the NO_RECORDS. "stem" variables,
and the NO_RECORDS_ONLY variable.

NO_RECORDS.1, ..., NO_RECORDS.n and NO_RECORDS.0
   A stem variable containing selectors that should NOT be subject
   to post-filter processing.

   Each of these values should contain a candidate selector string.

   For example:
      no_records.1='IMGS/'
      no_records.2='SAMPLES/SREFILTR.HTM
      no_records.3='HELP/PUB'
      no_records.0=3

      *  To speed up processing, abbreviation matching is done.  That is,
         wildcards are NOT recognized.
         For example:  IMGS/A.GIF would match no_records.1
                       IMGS2/A.GIF would NOT
                       HELP/PUBLIC/FOO.HTM would match no_records.3
                       HELP/PU/FOO.HTM would NOT
       * Reiterating: do NOT use * in the NO_RECORDS. stem variables
         Hint: See the discussion of the NOURL option, in  SREFLOGS.DOC,
               for a method of suppressing explicit entries to the
               common-log file.
       * You MUST include a NO_RECORDS.0=n variable, where n is the
         number of NO_RECORDS variables you've specified.
       * Case is ignored, \ are converted to /, and a leading / is stripped.

    If a request selector matches one of the no_records. variables,
    then post-filter processing (auditing, etc.) will NOT occur.

The use of no_records. variables allows you to compensate for
"drawback 3" -- the non-checking for a NO_POSTFILTER permission when dealing
with cached requests.  In addition, it can help improve peformance:

   SREFQUIK will check the PUBLIC_URLS for a matching "NORECORD"
   entry.  If one is found, then post-filter processing will not occur.
   The process of checking is a bit time consuming, especially compared
   to scanning the NO_RECORDS variables.  Furthermore, if you are
   a thorough and include a NO_RECORDS. entry that's equivalent
   to all of your NORECORD (and LITERAL_NORECORD) PUBLIC_URLS, then
   there is no reason to examine the PUBLIC_URLS.

Since being thorough is often easy, you can suppress "checking the
PUBLIC_URLS after a cached request" by enabling the NO_RECORDS_ONLY parameter.

NO_RECORDS_ONLY
   To further speed up processing, you can suppress examination of
   the PUBLIC_URLS after a cached request.
   If NO_RECORDS_ONLY=1, then just the NO_RECORDS. variables are checked.


Summarizing: if you are willing to edit SREFQUIK.80 and create a
complete set of NO_RECORDS. variables, then you can (slightly) improve
performance, and simultaneosly deal with one of the SREFQUIK drawbacks.

... and if you don't want to bother, SREFQUIK can still provide a significant
performance advantage.


Btw: You can change these SREFQUIK parameters "on the fly" -- you don't have
     to restart GoServe after changing them (in contrast, changes to
     SREFILTR.80 parameters necessitate shutting down and restarting GoServe).